A well known difficulty in data processing involves the occurrence of a system failure while a transaction is being processed. For example, a transaction may involve the steps necessary for transferring $100 from a customer's savings account to the customer's checking account. Suppose the $100 was deducted from the customer's savings account, then a system failure occurred before the amount was added to the customer's checking account. The customer's account information would be in error.
There are various conventional techniques to deal with this problem. A very common solution is to employ what is known as a two-phase commit. In such a protocol, the transaction is designated by a “Begin Transaction” operation. The transaction ends with either a “Commit” operation or a “Rollback” operation. The Commit is used to signal a successful completion of the transaction. The Rollback is used to signal that the transaction was unsuccessful. When a Commit is received, usually a database management system will then write the results to persistent storage (e.g., to DASD).
Although the two-phase commit is often useful, there are certain drawbacks. One major disadvantage is the overhead involved. Furthermore, this approach is not suitable in every processing environment. For instance, when executing a network of processes in which a graph of processing nodes can be dynamically changed, and where no a priori knowledge of the graph structure exists, it can be difficult using such an approach to even know when successful completion of the network has occurred.